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1.0 EXECUTIVE SUMMARY 


The National Aeronautics and Space Administration (NASA) Access 5 Project Office sponsored 
a cooperative collision avoidance flight demonstration program for unmanned aircraft systems 
(UAS). This flight test was accomplished between September 13 th and September 26 th 2005 
from the Mojave Airport, Mojave California. 

The objective of these flights was to collect data for the Access 5 Cooperative Collision 
Avoidance Work Package simulation effort. The Scaled Composites, LLC Proteus Optionally 
Piloted Vehicle (OPV) was chosen as the test platform. Proteus was manned by two on-board 
pilots but was also capable of being controlled from a Air Vehicle Control Station (AVCS) 
located on the ground. For this demonstration, Proteus was equipped with cooperative collision 
sensors and the required hardware and software to place the data on the downlink. 

Prior to the flight phase, a detailed set of flight test scenarios were developed to address the flight 
test objectives. Two cooperative collision avoidance sensors were utilized for detecting aircraft 
in the evaluation: Traffic Alert and Collision Avoidance System-11 (TCAS-II) and Automatic 
Dependent Surveillance Broadcast (ADS-B). A single intruder aircraft was used during all the 
flight testing, a NASA Gulfstream 111 (G-III). During the course of the testing, six geometrically 
different near-collision scenarios were evaluated. These six scenarios were each tested using 
various combinations of sensors and collision avoidance software. Of the 54 planned test points 
49 were accomplished successfully. Proteus flew a total of 21.5 hours during the testing and the 
G-lll flew 19.8 hours. The testing fully achieved all flight test objectives. 

A questionnaire was developed prior to the test and used to gain insight into the human interface 
of the UAS pilot with the system. After each test run, the UAS pilot was asked a series of 
questions designed to document the pilot’s response to the collision displays and his ability to 
maintain situational awareness during the scenario. 

The Flight 1PT will perform an analysis to determine the accuracy of the simulation model used 
to predict the location of the host aircraft downstream during an avoidance maneuver. The 
results of this analysis will be included in the technical report to be published later this month. 

The data collected by this flight program will be delivered to the Access 5 Cooperative Collision 
Avoidance (CCA) Work Package. The CCA work package is responsible for reporting on their 
analysis of this flight data. 
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2.0 INTRODUCTION 


2.1 General 

Access 5 is a national project to promote the safe and reliable utilization of unmanned aircraft 
systems (UAS) for defense, civil, and commercial applications. The goal of the project is to 
achieve routine access to the National Airspace System (NAS) for high altitude, long endurance 
(HALE) UAS in five years. The goal of Step 1 of Access 5 is to establish requirements for flight 
operations above FL430 in the NAS and demonstrate the capabilities necessary to achieve these 
requirements using cooperative collision avoidance (CCA) technologies. 

2.2 Background 

Due to the rapid advancement in HALE UAS technology spearheaded by the Department of 
Defense (DOD) and the National Aeronautics and Space Administration (NASA) investments, 
both industry and government have developed a need for routine access to the national airspace 
in order to fulfill their missions or meet a perceived commercial demand. DOD increasingly 
requires UAS presence in the national airspace for training and repositioning of assets, while an 
emerging national security need is to provide border and port protection, and continuous 
oversight of key infrastructure. Demand for civil and commercial UAS services is quickly 
growing in the areas of science, telecommunications, resource management, and disaster 
management. The routine access to the NAS by UAS would result in improved national 
security, expansion to the U.S. economy, and increased U.S. leadership in aviation. 

Certification procedures, criteria, and operating requirements that meet the Federal Aviation 
Administration (FAA)’s safety of flight approval have not yet been developed for any class of 
UAS. In addition, special subsystems that allow the unmanned aircraft to operate in the NAS 
without a human pilot onboard have not been fully developed and certified for use by the FAA. 
UAS pilots located in Air Vehicle Control Stations (AVCS) typically fly these unmanned aircraft 
(UA). Therefore, for UAS to operate with an “equivalent level of flight safety as that of a 
manned aircraft”, special subsystem-piloting aides such as sense and avoid subsystems must be 
utilized. These subsystems are able to locate other aircraft in the surrounding airspace and 
provide the UAS pilot with advisory information in sufficient time for the UAS pilot to 
maneuver the UA and avoid a potential collision. 

There are two essential types of airborne flight objects that must ultimately be detected: 
cooperative and non-cooperative. Cooperative aircraft, which comprise most of the total air 
traffic, are those aircraft that transmit a signal from their onboard Mode A, C, or S transponder or 
datalink transceiver. 

Probably the most common type of collision avoidance tool used to detect and locate cooperative 
aircraft is the Traffic Alert and Collision Avoidance System (TCAS), which is required on all 
aircraft in the United States that are capable of seating 10 or more passengers. The transponder 
signal from a cooperative aircraft is used by other aircraft’s TCAS equipment to display that 
aircraft’s position and altitude on a traffic display indicator in the TCAS-equipped aircraft. If the 
separation of TCAS equipped aircraft to other cooperative aircraft becomes a hazard, the TCAS 
equipment will alert the pilot(s) to the potential hazard by displaying a Traffic Advisory (TA). If 
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the situation is allowed to worsen, the TCAS equipment generates an avoidance maneuver or 
Resolution Advisory (RA) that directs the pilot, via the TCAS display and aural alert, to climb or 
descend in order to avoid a potential collision. 

A newly developed technology that is designed to improve situational awareness is the 
Automatic Dependent Surveillance-Broadcast (ADS-B). In typical applications, the ADS-B 
equipped aircraft uses a Global Positioning System (GPS) receiver to derive its precise position 
from the GPS constellation of satellites, and then combines that position with additional aircraft 
data, such as speed, heading, altitude and whether the aircraft is turning, climbing or descending. 
This information is then simultaneously broadcast via a digital datalink or Universal Access 
Transceiver (UAT) to other ADS-B capable aircraft and to ADS-B ground communication 
transceivers which relay the aircraft’s position and the additional information to Air Traffic 
Control centers in real time. Other ADS-B equipped aircraft and ground stations within about 
150 miles receive the UAT broadcasts and display the information on a computer screen. Pilots 
see the traffic on a Cockpit Display of Traffic Information (CDTI) display. Controllers on the 
ground can see the ADS-B targets on their regular traffic display screen, along with pure radar 
targets. 

Many small general-aviation airplanes, as well as all gliders and balloons, with very few 
exceptions, are not equipped with any transponder or transceiver. These aircraft are categorized 
as non-cooperative aircraft. 

This flight demonstration was focused on using cooperative technologies onboard the UAS 
during HALE flight. 

This report describes the flights conducted in the Isabella MOA between 21 September 2005 and 
28 September 2005 under the Access 5 Step 1 Cooperative Collision Avoidance Test Plan dated 
12 Aug 2005. 6 flights were flown, totaling 21.5 hours. 

3.0 OBJECTIVE 

The objective of this flight test was to collect data to validate the CCA simulation. Figure 1 
illustrates the points in the functional architecture at which data was collected. Sufficient data 
was collected to consider this objective fully met. 
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Figure 1 

Data Collection Points 
4.0 TEST ITEM DESCRIPTION 

Access 5 CCA Step 1 Technology Demonstration consisted of the Scaled Composites, LLC 
(SCI) Proteus Optionally Piloted Vehicle (OPV) with TCAS II and ADS-B sensors providing 
position information, and a Air Vehicle Control Station (AVCS) equipped with the Access 5 
Common Tool and with datalink delay insertion software/equipment. The Access 5 Common 
Tool, a laptop computer with unique application software, contained the collision avoidance 
system (CAS) algorithm and provided the collision avoidance display. 


Overall, the host vehicle (Proteus) used the installed sensors to detect and track intruder aircraft. 
This data was transmitted to the AVCS where a computer algorithm identified minimum 
distances and determined if an avoidance maneuver was required. If needed, an alert was 
generated for the UAS pilot via a display. The UAS pilot then performed the required avoidance 
maneuver through control commands sent to the test vehicle. The host vehicle maneuvered to 
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avoid the conflict. Lastly the onboard sensors transmitted data that the pilot used to determine 
when the avoidance maneuver was complete and if it was successful. 1 

Three different test architectures were demonstrated. 1) ADS-B sensors were used to determine 
the positions of the UA and intruder aircraft. That information was datalinked to the AVCS, 
where the CAS algorithm in the Common Tool (CT) determined if an avoidance maneuver was 
required, alerted the pilot and displayed an avoidance maneuver on the CA display for the pilot 
to follow. 2) TCAS sensors were used to determine UA and intruder relative position, datalink 
the data to the AVCS and the CT CAS algorithm was used to generate the required alerts and 
display an avoidance maneuver on the CA display for the pilot to follow. 3) The TCAS II 
system to include the FAA approved TCAS CAS algorithm, was used to generate the alerts on 
the Common Tool. The Common Tool displayed the avoidance maneuver for the pilot to follow. 


4.1 TEST ARTICLE 


4.1.1 Host Aircraft 


Scaled Composites provided Proteus OPV (Tail 
Number N281PR) equipped with TCAS-II and 
ADS-B subsystems (Figure 2). Proteus is a twin 
turbofan high altitude multi mission aircraft 
powered by Williams International FJ44-2E 
engines. It is designed to carry payloads in the 
2000-pound class to altitudes above 60,000 feet 
and remain on station up to 14 hours. 

Proteus was modified for this test by 
incorporating the cooperative TCAS II and the 
ADS-B sensor systems and software to collect 
sensor data and place it on the downlink. The 
other equipment used during this test is standard equipment that is on the aircraft at all times. 
Proteus was manned during all testing with a pilot and co-pilot. These individuals had the ability 
to retake command of the aircraft, at any time deemed necessary. The flight crew was provided 
by SCI and complied with FAA regulations. Flowever, Proteus was controlled from the ground 
for all test points. 

4.1. 1.1 Proteus Test Equipment 

The Proteus OPV was modified with a TCAS-II Processor, Control Panel, Directional Antenna, 
VSI/TRA Display, Mode S Diversity Transponder, RCZ Transponder and a Mode S Transponder 
Antenna. An ADS-B processor, OMNI antenna and GPS antenna were also installed. See 
Appendix G for specific part numbers, serial numbers, software versions and other configuration 
specifics relative to each demonstration flight. 



Figure 2 

SCI Proteus OPV 


1 See Sense-and-Avoid Equivalent Level of Safety Definition for Unmanned Aircraft Systems, Revision 9, 23 
November 2004. 
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4.1. 1.2 Proteus Antenna Locations 


Specific antenna locations for the host (Proteus) are depicted in the three figures below. 



ADS-BGPS 
Antenna (in 
window) 


VHF COMM1 (Comant Cl 238-1) 
FS 283 

Satcom (TT-5006A), FS 240 


UPR TCAS Directional Antenna 
(7515060-902), FS 172.8 


Mode S Transponder S65-5366-7L, FS 
143.3 


Weather Radar (Bendix King RDR 2000), FS 25.5 (In Nose Cone) 


Figure 3 

Proteus Front Aspect Antenna 
Locations (Top) 
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Transponder 1 (Comant Cl 105), FS 87.1 
VHF Comml (Comant Ci 238-1), FS 87.1 
Marker Beacon (Comant Cl 118), FS 116.1 


LWR TCAS Directional Antenna 
(7514060-902), FS 152.1 

Mode S Transponder S65-5366-7L, FS 
187.1 


Figure 4 

Proteus Front Aspect Antenna 
Locations (Bottom) 
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Transponder 2 ( Comant Cl 105), FS 560 

LOS TM (Comant Ci 105), FS 560 


Glideslope, Localizer, VOR 
(Comant Cl 105), FS 660 


Figure 5 

Proteus Rear Aspect Antenna 
Locations (Bottom) 


4.1.2 Air Vehicle Control Station 

Proteus was controlled remotely via the Air Vehicle Control Station (AVCS). Proteus’ state of 
health information and GPS position were provided to the UAS pilot for monitoring system- 
health and navigation/situational awareness, respectively. The UAS pilot had the ability to 
command and control Proteus from the AVCS by issuing commands that control the vehicle 
through the onboard flight management system. The UAS pilot was able to change the heading 
and altitude of the vehicle and select specific rates of climbs and descents through keyboard and 
mouse inputs. 
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GPS moving map 
showing Proteus’ 
position. 


Figure 6 

SCI Proteus UAS Pilot Station Display 
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AVCS 


Figure 7 

Air Vehicle Control Station Architecture 


For this test, the AVCS was modified to interface with the CAS algorithm and the CCA display, 
both provided by the Common Tool. The AVCS provided the Common Tool with sensor data 
from the Proteus downlink. The CCA display was designed to mimic the TCAS-II vertical speed 
indicator (VSI) display and to provide the UAS pilot with aural and visual maneuver advisories 
whenever the CAS algorithm determined a maneuver was necessary. 
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Figure 8 

Common Tool CCA Display 

The AVCS included a base-station radio that can be used to talk directly with the test participants 
on SCI’s VHF test frequencies (123.375 Primary, 123.45 Secondary) as well as space for a 
limited number of test observers. The AVCS was located at the SCI facilities in Mojave, CA. 

4.1.3 Intruder Aircraft 

The intruder aircraft was chosen to represent the cruise speed that the majority of the aircraft that 
operate above FL430 use. NASA Dryden provided a Gulfstream III (G III) (Figure 9) for these 
tests. A Garmin GDL 90 Universal Access Transceiver (UAT) for ADS-B was added to the G- 
III, and no special software was required. This aircraft was manned by NASA personnel and 
flown in accordance with FAA and NASA regulations. 
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Figure 9 

NASA Intruder Vehicle 
4.1.3. 1 Gulfstream III Test Equipment 

NASA’s G-III was equipped with TCAS-II processor, control panel, transponder and antennas. 
An ADS-B Processor, was installed and integrated with existing omni and GPS antennas in 
support of the test. See Appendix G for specific part numbers, serial numbers, software versions 
and other configuration specifics relative to each demonstration flight. 

5.0 SIMULATION 

5.1 OVERVIEW 

The Common Tool (CT), a customizable situational awareness display, developed by Access 5, 
provided the flexibility and mobility to insert display applications or provide simulations of 
many different platforms into multiple test environments. The primary purpose of the common 
tool for this flight technology demonstration was to communicate with the Proteus ground station 
and display TCAS and ADS-B information to the operator. 

The common tool included a generic aircraft model that could be tailored to match the 
performance parameters of a given aircraft as well as a simple intruder position model. The 
intruder position model information can be fed to the CCA display to simulate an intruder target 
while the generic model is running. The display issues maneuver advisories from the CAS 
algorithm and the operator can command a climb or dive maneuver in response to those 
advisories. 


5.2 PRE-FLIGHT SIMULATION 

Several simulation sessions using the generic vehicle model in the common tool were performed 
prior to the tech demo flights to aid in test planning. Each of the test plan scenarios was run 
several times with each release of the common tool (starting with common tool release 4.0) to 
demonstrate run consistency. With common tool 4.0, each scenario (except scenario 3) was run 
at least 10 times. With common tool 4.1 and 4.2, each scenario was run at least 5 times. After the 
common tool 4.2 runs, the minimum separation distance and the time of the maneuver advisory 
were averaged for each scenario. The maneuver advisory time was very consistent run to run, but 
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the minimum separation distance was quite variable due to variability in the operator response to 
the maneuver advisories. The maneuver advisory (climb or dive) was included in the test cards as 
the expected maneuver, while the warning time and minimum separation distance were used as a 
check on the test team’s safety planning efforts. Since the generic model will not be validated 
until after the flights, these results (especially the minimum separation distance) could not be 
used as truth data. 

5.3 RESULTS 

Some enhancements were made to the common tool as a result of this simulation activity. 
Among those enhancements are the ability to set climb and dive rates in the intruder model and 
the layout of the CCA display. 

The common tool simulation will be compared with flight data to validate the generic model 
tailored to match Proteus performance. The results of this comparison will be included in the 
technical report to be released by the Flight IPT in December 2005. 


6.0 FLIGHT TESTING 
6.1 OVERVIEW 

Flight tests were executed in accordance with the NASA Access 5 Cooperative Collision 
Avoidance Step 1 Technology Demonstration Flight Test Plan, Revision 1.5, dated 11 August 
2005. 

Although Access 5 Step 1 activities are focused on obtaining access to the NAS above FL 430, 
the CCA flight demonstrations were planned at a test altitude of 15,000 feet. This altitude was 
chosen for two reasons, the primary reason being test efficiency (no flight hours were expended 
getting to altitude), the secondary reason being to allow sufficient margin for the intruder to 
execute the desired collision scenarios at FL 430. The choice of 15,000 feet also had the 
advantage of allowing the test to be executed above the Inyokern Transit Area (an area of busy 
airline traffic) and below Class A airspace. 

Proteus’s test airspeed (110 KIAS) was chosen to be in the heart of Proteus’s speed envelope at 
15,000 feet. The intruder speed (300 KIAS) was then tailored to match the closure rates between 
a HALE aircraft and the airline traffic that would typically be seen at FL 430 while staying 
inside the G-III speed operating envelope. The co-heading scenarios featured a closure rate of 
247 KTAS while the head-on scenarios featured a closure rate of 533 KTAS. 

Each scenario had a 300-foot altitude separation buffer built into the intruder aircraft’s flight path 
for safety concerns. The intruder aircraft would fly low to improve G-III pilot visibility. 

For safety precautions, the test procedures also provided explicit instructions for the test pilots to 
react appropriately in the event of an ABORT situation. During an ABORT the onboard Proteus 
pilots would assume control of Proteus and both aircraft would execute specific instructions in 
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accordance with that test card . Any test participant, on the ground or in the air had the authority 
to call an ABORT in the interest of safety. 


Because no other external aids such as radar tracking, were available to aid in separation and 
situational control of the airborne participants, procedural control through radio procedures was 
paramount to mission success. Detailed test run procedures were developed that emphasized 
specific radio transmissions and placed in the test card deck. All participants were briefed on 
these procedures due to their criticality 2 3 . The Test Conductor was responsible for ensuring these 
radio procedures were maintained. 

The tests were flown under visual meteorological conditions (VMC) inside the boundaries of the 
Isabella Military Operating Airspace (MO A). Joshua Control provided active radar monitoring 
and alerted the participants if non-participating aircraft came within 2000 feet or 5 miles of the 
test aircraft. Detailed planning was required in order to ensure safety and to generate the near- 
collision geometry scenarios required for the test. A strict set of mission mles was developed 
with these aims in mind. A great deal of time and effort went into the establishment of ABORT 
procedures. These were designed to be as consistent as possible yet still remain as effective as 
possible. These procedures were drawn pictorially on each test card and briefed prior to each run 
by the Test Conductor 4 . 

NASA aircraft and personnel operated out of Edwards AFB. SCI aircraft, the AVCS, and SCI 
personnel operated out of Mojave Airport. Figure 10 shows the working airspace and the 
navigational points used to set up the test scenarios. 


2 See test cards at Appendix J 

3 See Test Run Procedure in Test Cards at Appendix J 

4 See Test Conduct in Test Cards at Appendix J 
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Figure 10 
Test Area 


Substantial effort was required to bring together the required equipment and software from 
multiple vendors, suppliers, and team members in order to bring this demonstration to 
completion. Some of the issues involved interfacing with proprietary software code as well as 
hardware installation in the host aircraft. During the integration phase, Proteus flew five sorties 
while the G-1II flew one sortie. An additional two checkout sorties were flown mid-test to 
investigate a problem with the C2 link and to verify a change to the CAS algorithm. 
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The demonstration flights fully satisfied the test objective; however, many difficulties were 
encountered including unacceptable weather, C2 problems, intruder launch delays, and merge 
timing issues. These difficulties caused a presumably conservative estimate of three successful 
test points per flight hour to be more accurate than anticipated. 

Proteus flew a total of 21.5 demonstration flight hours and the G-III flew a total of 19.8 
demonstration flight hours. 

Seventy two total data passes were flown. Fifty-three of the fifty-four test points were attempted 
and forty-nine of the fifty-four test points were accomplished successfully. Additionally, 6 runs 
were accomplished twice - once each with different versions of the Common Tool and CAS 
algorithm. 

Forty-five of the seventy-two passes included an avoidance maneuver through the point of 
closest approach of the two aircraft. 

The flight log, test point log, and quick look flight reports are all included as appendices to this 
report. 

In accordance with the Configuration Control Plan, Anomaly Reports were generated to 
document anomalies during the course of the test. Throughout the Checkout and Demonstration 
Flight phases, 17 Anomaly Reports were generated. The anomalies reported are categorized 
below: 

• 3 test enhancements/common tool capability upgrades 

• 3 anomalies having to do with C2 dropouts caused by interference 

• 4 display enhancements 

• 1 documenting a discrepancy between the software and the documentation 

• 1 documenting inconsistent engineering units 

• 1 documenting an inconsistency in the altitude sent to the CAS algorithm 

• 2 documenting problems found during checkout that were fixed during that phase 

• 2 documenting possible anomalies in the CAS algorithm and the common tool generic 
model that will be examined during data analysis. 

The anomaly reports are included in Appendix K to this report. 

7.0 DATA 

Data processing is underway and several data sets have been delivered to the CCA work package 
already with the remainder scheduled to be delivered by 9 December, 2005. The data available is 
shown below. The following sections describe the data sets. 

7.1 PROTEUS AIRBORNE AND GROUND RECORDER DATA 

Proteus Airborne and Ground Recorder data are provided in text files. Each file contains data for 
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one flight. The files are arranged in folders by Proteus flight number. The data is in engineering 
units and is both tab and space-delimited. Most files are too large to be imported directly into 
Excel. Parameter lists which include a brief description of each parameter recorded and the 
applicable engineering units are included in the folder of the first flight to which the list applied. 
The parameter lists changed after the first flight, but remained constant for the remainder of the 
flights. For questions regarding Proteus data, contact Mike Alsbury of Scaled Composites at 
(661) 824-6388. 

7.2 COMMON TOOL DATA 

Common Tool data is provided in text files. Each file contains data for one testpoint. The files 
are arranged in folders by Access 5 flight number. The data is in engineering units and is both 
tab and space-delimited. Most files are small enough to be imported to Excel directly. Parameters 
other than those requested in the parameter list may be provided. The files can be “played back” 
on the common tool, but they do not contain enough information to drive the Collision 
Avoidance display with complete information during the playback. For questions regarding 
Common Tool Data, contact Russell Turner of Lockheed Martin Aeronautics Company at (817) 
935-4355. 


7.3 AVCS OPERATOR VIDEO 

A video recorder was set up behind the AVCS operator in an attempt to capture video of the 
operator and both the AVCS and Collision Avoidance displays. The video is not time-stamped. 
Audio is ambient only and is of poor quality. For the first flight, the video was allowed to run 
throughout the entire flight, however, the recorder sometimes turned itself off and since there 
was no obvious alert to either this condition or to when the recorder needed a new tape, much of 
the flight was probably not captured. After the first flight, the Flight IPT Lead and the Test 
Conductor tag-teamed the video recorder and attempted to turn it on at the beginning of each 
testpoint and off at the end of each testpoint. There is no indication of time or testpoint on the 
tape. Some flights required multiple tapes. For questions regarding the AVCS Operator Video, 
contact CJ Bixby of NASA Diyden Flight Research Center at (661) 276-3394. 

7.4 G-III DATA 

G-III data is provided in text files. Each file contains data for one parameter during one flight. 
The files are arranged in folders by G-III flight number. The data is in engineering units and does 
not contain carriage returns. For questions regarding the G-III data, contact Richard Hang of 
NASA Diyden Flight Research Center at (661) 276-2090. 

7.5 HSI QUESTIONNAIRE 

The HSI questionnaire was administered to the AVCS operator at the first successful conclusion 
of each test point. The questionnaire was administered only once per test point, i.e., it was not 
administered on repeats. At the conclusion of a test point, the scribe queried the AVCS operator 
and recorded the response on the questionnaire matrix. A typed version of the matrix is available 
in appendix F to this report. 

7.6 SCRIBE NOTES 
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The official record of test events is contained in the scribe notes (Appendix I). The control room 
at Scaled Composites did not offer a time display that was visible to all participants. Effort was 
made to synchronous various clocks and watches available to the test team to aircraft time and 
those efforts were usually accurate to within a second. The time recorded in the scribe notes is 
local time. The terms “yellow warning” and “red warning” refer to states of the CCA display in 
which the host aircraft symbol turns yellow to indicate a possible traffic conflict and red to 
indicate that an avoidance maneuver should be executed. The term “all clear” refers to a state of 
the CCA display in which an aural announcement is made when the host is clear of a previous 
traffic conflict. The terms “climb climb” and “descend descend” refer to aural warnings made by 
the CCA display to coincide with a visual maneuver advisory. The scribe notes are included as 
an appendix to this report. Questions regarding the scribe notes should be directed to Jon 
Bachman of Modern Technology Solutions, Inc. (MTSI) at (505) 430 9724. 

7.7 PARAMETER LIST 

The final parameter list is included in Appendix C to this report. The parameter list contains the 
following data: Signal Number; Recorded at; Signal Name; Flight Management Systems (FMS) 
ID; Description; Source of Reference; Units; Dimensions; Format; Type; Bit Count; Resolution; 
Tower Bound; Upper Bound; TM Downlink Rate; Record Rate; and Required For. 

8.0 LESSONS LEARNED 

• Test planners and test customers must have thorough knowledge of the test aircraft . 

Mission planning for the test was critical for the intercepts and was done without 
detailed knowledge of the navigational systems of the two aircraft involved. It was 
not discovered until after testing began that neither of the navigation systems was 
capable of providing time to go to the merge point in seconds and handheld GPS units 
had to be used in both cockpits. The test customer needs to participate in mission 
planning. For example, data analysis was complicated somewhat by the intruder 
aircraft maneuvering to cross at the merge point with the proper conditions. It would 
have been better if the intruder aircraft maintained a constant track that could be 
modeled easier in simulation. 


Due to autopilot limitations, hand-flying the outbound legs were found more efficient 
than allowing the autopilot to fly those legs. This was assumed to be the case during 
the planning phase, but since the planners did not have a thorough understanding of 
the autopilot, was not given to the pilots as an instruction. As a consequence, this 
lesson was learned more than once as new pilots tried the same technique previously 
demonstrated not to work well. 

The aircrews found that the TCAS display provided quite a bit of their awareness 
with regard to the position of the other aircraft. In fact, the intruder aircraft became so 
dependent on their display that they protested turning it off for some of the testpoints. 
Since it was not deemed technically necessary to turn the TCAS off for those 
testpoints, the Test Director allowed the intruder aircraft to keep the TCAS display on 
for all of the testpoints. The TCAS display should have been deemed mission-critical 
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equipment for this test. 


• Provide situational awareness in the control room. 


This collision avoidance demonstration was planned without the availability of many 
of the tools upon which the test community has come to rely. Since there was no air- 
to-air TACAN or radar tracking, the safety responsibility fell wholly to the crews 
onboard the aircraft. The control room could provide little help because situational 
awareness with regard to relative aircraft positions was provided by the CCA display 
- the very system that was under test - and through procedural tracing via timing. 
With these limitations, visual contact between the aircraft and coordination of time to 
go to the established merge point became paramount to safe execution of the test. 
While the tests were conducted safely, test efficiency and safety could both be 
enhanced by providing situational awareness in the control room. 

Coordinating a specific merge point time was much more complex than readily 
apparent. During planning discussions with the aircrew, it was not clear which of the 
methods discussed was preferred. Once flight testing began, it became clear that the 
best method was for the control room to establish a local merge time and get 
concurrence from each cockpit that they could make that particular time. From that 
point, it was a matter of each cockpit monitoring and updating their time to go every 
minute. This, however, was still challenging for the pilots to accomplish when winds 
were high. Had the control room had some situational awareness, the test conductor 
could have helped the aircraft keep on schedule and, perhaps more importantly, could 
have clearly seen when a scenario wasn’t going to work and called a knock- it-off long 
before either aircraft approached the merge point. This would have dramatically 
improved test efficiency. 

Although the safety planning called for the separation responsibility to lie in the 
cockpit of the intruder aircraft, it was very tempting for the test team to want to put 
some of that responsibility in the control room. In fact, coordination of the visual 
contact rule was best done in the control room. However, the control room crew must 
diligently refuse to use the situational awareness provided by the system under test - 
the CCA display - to inform any safety decisions. 

The visual contact rule was overly restrictive when using an OPV rather than a UAV 
as the host aircraft. The host aircrew often had visual on the intruder long before the 
intruder had visual on the host (the intruder was larger, had more contrasting paint, 
and its engines created visual smoke). But the rule stated that the intruder must have 
the host in sight to continue the run. On one occasion, a run was aborted for the 15 
second rule about one second before the intruder finally gained visual contact. In that 
case, the host had visual on the intruder for several seconds before the run was 
aborted. After this incident, the mle was changed to allow the run to continue if either 
cockpit had visual on the other aircraft and testing continued without another abort 
for a lack of visual. Better real time monitoring of the participating aircraft with 
positive control from the control room would have been another way of 
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accomplishing this and may be the only safe way to accomplish this in the case where 
one of the participating aircraft is a UAV. 


• If situational awareness is unavailable in the control room, a very strict 
communication protocol must be established and adhered to . 

A mission rule was established where the intruder cockpit was required to have visual 
contact with the host aircraft not later than 15 seconds time to go (TTG) to the merge 
point, or the run must be aborted. However, due to timing errors there was the 
possibility of each aircraft arriving at the merge point at different times. Keeping 
track of this situation was complicated due to the lack of real-time monitoring in the 
control room. Once the intruder had visual on the host the test point would run to 
completion, often overshooting the merge point by many seconds. It is imperative 
that communication procedures be established and practiced before test flights begin 
to ensure that ah parties understand the procedures and their necessity. 

• Consider visual enhancement of either or both aircraft depending on which aircraft 
is manned. 


The bottom line: Small airplanes are hard to see. Since the safety planning rested so 
completely on visual contact between the two aircraft, pilots with above-average 
vision should have been a mission requirement. 

With the small size of UAVs and OPVs, some enhancement of the visual signature is 
recommended. During the planning phase the test team had considered implementing 
a smoke system on the host aircraft, but the pilots convinced the planners that smoke 
would not be necessary. This leads to two lessons: 1) pilots can overestimate their 
ability to see other aircraft and 2) visual enhancement of small aircraft is desirable. 

• Centralize interface requirements — planners, conductors, and customers must have 
a consistent view of the operation. 

Interface requirements were developed in at least 3 different places (the CCA work 
package, the CCA equipment vendors, and the common tool developers). This 
information was never sufficiently integrated leading to confusion during the 
integration process and to last-minute changes. This could have been mitigated by 
either centralizing the interface requirements or allowing the Flight IPT integration 
team enough access to the test vehicle integration process to head off confusion. 

• Use a traditional organizational structure to get work done . 

The Access 5 program was structured to emphasize collaboration among the various 
organizations participating in the project. While this structure works well for 
planning, it hampered execution. The distribution of authority was such that although 
the Flight IPT was responsible for executing the flight demonstrations, it had limited 
authority to do so. Much of the time and effort that could have been expended on test 
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planning was spent establishing authority and credibility with other groups inside the 
project and gaining approval from the project to proceed to the next step in planning. 
To make matters worse, the Flight IPT was also operating in a 
collaborative/consensus mode for much of the time that should have been used for 
initial test planning. Since consensus could rarely be gained during weekly telecons 
with spotty individual attendance, no test planning occurred. Once the Flight IPT 
switched to an authoritarian mode of operation with a strong leader and individuals 
charged with executing and reporting back to the team, test planning got off the 
ground. The collaborative model should be replaced by a more traditional 
organization with clearly defined roles and responsibilities at the working level in 
order to increase efficiency and reduce schedule risk. 

• If you can’t co-locate, meet often . 

The Access 5 program in general and the Flight IPT in particular consist of 
individuals from a number of organizations located across the country. Attempts to 
coordinate test planning activities remotely across the various locations were very 
inefficient. During telecons, only the loudest voices are heard and body language was 
completely lost. Face-to-face meetings where the participants dedicated a day or two 
to the business at hand were found to be a much more efficient means to come to a 
lasting consensus among participants. This was especially true during the initial 
stages when the personalities and strengths of each individual were unknown. Each 
major activity is best accomplished with a face-to-face kickoff meeting to assign roles 
and responsibilities followed by a final face-to-face coordination meeting to review 
and approve the products of that activity. 

• The test team must control the test articles . 

The Access 5 program sought to leverage assets of participating organizations to 
accomplish the goals of the program. While this model appears to be efficient and 
cost-effective, it leaves the project very vulnerable to the shifting priorities and 
schedules of the participating organizations. Since the project does not own the test 
articles (and in many cases gains access to the test articles through in-kind 
contributions rather than traditional contract mechanisms), the project has limited 
ability to guarantee the availability of test articles or expertise to advise in the use of 
the test articles. Contract mechanisms such as payment milestones must be in place to 
aid the project in keeping some control over the project schedule. 
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9.0 APPENDICES 


The following appendices are supporting documentation to this report. If required, they can be 
obtained by contacting NASA DFRC. Appendices are not proprietary unless annotated as such. 

A. Test Condition Matrix 

B. Flight Log 

C. Parameter List 

D. CCA Tech Demo Summary (proprietary) 

E. Test Point Log 

F. HSI UAS Pilot Questionnaire 

G. Configuration Log 

H. Quick Look Reports 

I. Scribe Notes 

J. Flight Card 

K. Anomaly Report 
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